Detecting Spurious Counterexamples Efficiently in 
Abstract Model Checking^^ 

Cong Tian and Zhenhua Duan* 

ICTT and ISN Laboratory, Xidian University, Xi'an, 710071, P.R. China 



Abstract 

Abstraction is one of the most important strategies for dealing with the state space 
explosion problem in model checking. In the abstract model, the state space is 
largely reduced, however, a counterexample found in such a model may not be a 
real counterexample in the concrete model. Accordingly, the abstract model needs 
to be further refined. How to check whether or not a reported counterexample is 
spurious is a key problem in the abstraction-refinement loop. In this paper, a 
formal definition for spurious path is given. Based on it, efficient algorithms for 
detecting spurious counterexamples are proposed. 
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1. Introduction 

Model checking is an important approach for the verification of hardware, 
software, multi-agent systems, communication protocols, embedded systems and 
so forth. The term model checking was coined by Clarke and Emerson [1], as well 
as Sifakis and Queille [2], independently. The earlier model checking algorithms 
explicitly enumerated the reachable states of the system in order to check the cor- 
rectness of a given specification. This restricted the capacity of model checkers to 
systems with a few million states. Since the number of states can grow exponen- 
tially in the number of variables, early implementations were only able to handle 
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small designs and did not scale to examples with industrial complexity. To com- 
bat this, kinds of methods, such as abstraction, partial order reduction, OBDD, 
symmetry and bound technique are applied to model checking to reduce the state 
space for efficient verification. Thanks to these efforts, model checking has been 
one of the most successful verification approaches which is widely adopted in 
industrial community. 

Among the techniques for reducing the state space, abstraction is certainly 
the most important one. Abstraction technique preserves all the behaviors of the 
concrete system but may introduce behaviors that are not present originally. Thus, 
if a property (i.e. a temporal logic formula) is satisfied in the abstract model, it 
will still be satisfied in the concrete model. However, if a property is unsatisfiable 
in the abstract model, it may still be satisfied in the concrete model, and none of 
the behaviors that violate the property in the abstract model can be reproduced 
in the concrete model. In this case, the counterexample is said to be spurious. 
Thus, when a spurious counterexample is found, the abstraction should be refined 
in order to eliminate the spurious behaviors. This process is repeated until either 
a real counterexample is found or the abstract model satisfies the property. 

In the abstraction-refinement loop, how to check whether or not a reported 
counterexample is spurious is a key problem. In [3], algorithm SplitPath is pre- 
sented for checking whether or not a counterexample is spurious, and a SAT solver 
is employed to implement it 10, 113] • In SplitPath, whether or not a counterexam- 
ple is spurious can be checked by detecting the first failure state in the counterex- 
ample. If a failure state is found, the counterexample is spurious, otherwise, the 
counterexample is a real one. However, whether or not a state, say Sj, is a failure 
state relies on the prefix of the counterexample sq, si, Sj. This brings in a poly- 
nomial number of unwinding of the loop in an infinite counterexample iIb. 151. 

In this paper, based on a formal definition of failure states, spurious paths 
are re-analyzed, and a new approach for checking spurious counterexamples is 
proposed. Within this approach, whether or not a counterexample is spurious 
still depends on the existence of failure states in the counterexample. Instead 
of the prefix, to checking whether or not a state s, is a failure state is only up 
to 5,'s pre- and post- states in the counterexample. Based on this, for an infinite 
counterexample, the polynomial number of unwinding of the loop can be avoided. 
Further, the algorithm can be easily improved by detecting the heaviest failure 
state such that a number of model checking iterations can be saved in the whole 
abstract-refinement loop. In addition, the algorithm can be naturally parallelled. 

The rest parts of the paper are organized as follows. The next section briefly 
presents the preliminaries in abstraction-refinement. In section 3, why spurious 
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counterexamples occur is analyzed intuitively and algorithm SplitPath is briefly 
presented. In section 4, a formal definition of spurious counterexamples is given 
with respect to the formal definition of failure states. Further, in section 5, efficient 
algorithms for checking whether or not a counterexample in the abstract model is 
spurious are presented. Finally, conclusions are drawn in section 6. 



2. Abstraction and Refinement 

There are many techniques for obtaining the abstract models [@, [sifl^]- We 
follow the counterexample guided abstraction and refinement method proposed by 
Clarke, etc, where abstraction is performed by selecting a set of variables which 
are insensitive to the desired property to be invisible We use h : S — > 5 to 
denote an abstract function, where S is the set of all states in the original model, 
and S the set of all states in the abstract model. For clearance, s, si, sj, ... are 
usually used to denote the states in the original model, and s, si, sj, ... indicate 
the states in the abstract model. Further, for a state s in the abstract model, h'{s) 
is used to denote the set of origins of s in the original model. 

The abstraction-refinement loop is depicted in FigdJ Initially, the abstract 
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Figure 1 : Abstraction refinement loop 

model M' is obtained by the abstract function h. Then a model checker is em- 
ployed to check whether or not the abstract model satisfies the desired property. If 
no errors are found, the model is correct. Otherwise, a counterexample is reported 
and rechecked by a checker which is used to check whether or not a counterexam- 
ple is spurious. If the counterexample is not spurious, it will be a real counterex- 
ample that violates the system; otherwise, the counterexample is spurious, and a 
refining tool is used to refine the abstract model ||3i|4l|5i|7i|9i[l3|]. Subsequently, 



the refined abstract model is checked with the model checker again until either a 
real counterexample is found or the model is checked to be correct. In this paper, 
we concentrate on the how to check whether or not a counterexample is spurious. 
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3. Spurious Paths 



To check a spurious counterexample efficiently, we first show why spurious 
paths occur intuitively with an example. Then we briefly present the basic idea 
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of algorithm SplitPath which is used in [|3| 
counterexample is spurious. 



3. 1 . Why Spurious Paths ? 

Abstraction technique preserves all the behaviors of the concrete system but 
may introduce behaviors that are not present originally. Therefore, when imple- 
menting the model checker with the abstract model, some reported counterexam- 
ples will not be real counterexamples that violate the desired property. This is 
intuitively illustrated by the traffic lights controller example Jsl]. 

Example 1. For the traffic light controller in Fig. [2](1), by making variable color 
invisible, an abstract model can be obtained as shown in Fig. [21(2). We want to 
prove u<>{state = stop) (any time, the state of the light will be stop sometimes 
in the future). By implementing model checking with the abstract model, a coun- 
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Figure 2: Traffic Light Controller 



terexample, si, S2, S2, S2, ... will be reported. However, in the concrete model, such 
a behavior cannot be found. So, this is not a real counterexample. □ 

3.2. Detecting Spurious Counterexample with SplitPath 

In Js]], algorithms SplitPath is presented for checking whether or not a finite 
counterexample is spurious. In SplitPath, as illustrated in FigjSl initially, the set. 
Mo, of starting states falling into h'{so). 

Mo = / n h~(so) 
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is computed. Then for the image of the states in / n /i (sq), i.e. R(I n h (sq)), the 
set of states falling into h'(si). 

Ml = Mo n h-(si) = R{I n h-{si)) n /z-(f2) 

is computed. Generally, for any / > 1, 

Mi = R(Mi^i)nh-{Si) 

= R(R(Mi^2) n h-isr-i)) n h-(sd 
= R{R{R{Mi^i) n h-m) n /z-(5r-i)) n 

= n r(fi)) n ... n ^(^r-i)) n 

is computed recursively. For some state s/,, k > 1, if M^. = 0, ^•^li is a failure 
state. Note that if Mo = 0, sq is a failure state. To check whether or not a finite 
counterexample is spurious, Mo, Mi, M2, ... are computed in turn until the first 
state Sk where Mt = is found, or the last state in the counterexample is reached. 




Figure 3: Algorithm SpliiPath 



For infinite counterexamples, it is more complicated to be dealt with since the 
last state in the counterexample can never be reached. Thus, a polynomial number 
of unwinding of the loop in the counterexample is needed That is an infinite 
counterexample can be reduced to a finite counterexample by unwinding the loop 
for a polynomial number of times. Accordingly, SplitPath can be used again to 
check whether or not this infinite counterexample is spurious. 

4. Failure States and Spurious Counterexamples 

In 10, HI], a spurious counterexample is informally defined by: a counterex- 
ample in the abstract model which does not exist in the concrete model. In this 
section, we give a formal definition for spurious counterexamples based on the the 
formal definition of failure states. 
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To this end, , In\, In" and /n? are defined first: 



/n° = 


- {s \ s e h {s 


,), s' e h (sf-i) and (s', s) e R] 


H - 


- {s \ s £ h'(s 


i), s' e In^. and s) e R} 


In" -- 


- {s \ s € h~{s 


,), s' s /<- 1 and (s', s) e R} 




CO 





/=0 



Clearly, /n° denotes the set of states in /z (f,) with inputting edges from the states 
in h~(SiLi), and In\ stands for the set of states in (f,) with inputting edges from 
the states in and Inj means the set of states in /z (f,) with inputting edges 
from the states in In\ , and so on. Thus, In^. denotes the set of states in h~{Si) that 
are reachable from some state in h'isf-i) as illustrated in the lower gray part in 

H+l n 

Fig. m Note that there must exist a natural number n, such that IJ In'. = [J In\ 

1=0 !=0 ^' 

since h~{si) is finite. Note that for state sq, 

Inl = {s\seih-{so)f^I)} 

In\ = {s \ s e h'iso), s' e In^. and {s\ s) e R} 

That is only /n^. is defined differently since there are no pre states. 



Out -a 




Figure 4: /n,- and Out§i 

Similarly, Oufl, Out], Outi and Outs: can also be defined. 

Outl = {s\seh-(si),s' eh-(sf+i)and(s,s')eR} 
Outi = {s\s e h-(si), s' e Out^. and {s, s') e R} 
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Out'l = {s\se h-(si), s' e Ouff^ and {s, s') e R} 

oo 

Outs = U Outi 

1=0 

Where Oufi~ denotes the set of states in h~(si) with outputting edges to the states 
in h'isf+i), and Out] stands for the set of states in h'(Sj) with outputting edges 
to the states in Oufi. , and Outl means the set of states in h~(Si) with outputting 
edges to the states in Out] , and so on. Thus, Out^. denotes the set of states in 
/z (f,) from which some state in are reachable as depicted in the higher 

gray part in Fig. |4l Similar to lui., there must exist a natural number n, such that 

n+l n 

U Out'- = U Outl . Note that for the last state s,, in a finite counterexample, 

,•=0 ^' (=0 

Out°, = {s\se h-(sn) n F} 

Out]. = {s \ s G h~{sn), s' e Out^. , and {s, s') e R} 

where F is the set of states without any successors in the original model. 
Accordingly, a failure state can be defined as follows. 

Definition 1. (Failure States) A state f, in a counterexample ft is a failure state 
if, and only if In^. Pi Out^- = 0. □ 

Further, given a failure state 5, in a counterexample ft, the set of the origins of 
Si, h'(si), is separated into three sets, !D = In^. (the set of dead states), S = Out^. 
(the set of bad states) and I = h^isi) \ (2) U S) (the set of the isolated states). 

Definition 2. (Spurious Counterexamples) A counterexample ft in an abstract 
model K is spurious if there exists at least one failure state Si in ft □ 

Example 2. Fig. |5] shows a spurious counterexample where state 2 is a failure 
state. 

In the set, (2) = {7, 8, 9}, of the origins of state 2, 9 is a dead state, 7 is a bad 
state, and 8 is an isolated state. □ 

5. Algorithms for Detecting Spurious Counterexamples 

Based on the formal definition of spurious counterexample, new algorithms 
for checking whether or not a counterexample is spurious are presented in this 
section. 
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Figure 5: A Spurious Path 

5.1. Algorithm by Detecting the First Failure State 

Algorithm CheckSpurious-I takes a counterexample as input and outputs the 
first failure state in the counterexample. Note that a counterexample may be a 
finite path < ^o, ■^i, >, n > 0, or an infinite path < sq, si, (si, sj)'^ >, 
< i < j, with a loop suffix (a suffix produced by a loop). For the finite one, 
it can be checked directly; while for an infinite one, we need only to check its 
Complete Finite Prefix (CFP) < sq, si, 5„ sj > since whether or not a state 5,- 
is a failure state only relies on its pre and post states. It is pointed out that in the 
CFP < Sq, si, Sj, Sj > of an infinite counterexample, 

Outl = {s\se h-(sj), s' e h'(si) and (s, s') e R} 
Out\ = {s\s e h-(sj), s' G Out°, and (s, s') e R} 

since the post state of Sj is f,-. 
Algorithm 1 : CheckSpurious-ICIT) 

Input: a counterexample H =< so,Si,...,s„ > in the abstract model K = 
(S ,So,R,L), and the original model K = (S,So,R,L) 
Output: a failure state Sf 

1: Initialization: int i = 0; 

2: while i < ndo 

3: if Irig. n Out,'. i^id,i = i+1; 

4: else return Sf = sf, break; 

5: end while 

6: if i == n + \, return ft is a real counterexample; 
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Algorithm Analyzing. In algorithm CheckSpurious-I, to check whether or not a 
state Si is a failure state only relies on f,'s pre and post states, 5," i and s^i; while in 
algorithm SplitPath, to check state is up to the prefix, sq, 5," 1, of f,. Based on 
this, to check a periodic infinite counterexample, several repetitions of the periodic 
parts are needed in SplitPath. In contrast, this can be easily done by checking 
the complete finite prefix < si, Si, Si, Sj > in algorithm CheckSpurious-I. 
Thus, the polynomial number of unwinding of the loop can be avoided. That is 
for infinite counterexamples, the finite prefix to be checked will be polynomial 
shorter than the one in algorithm SplitPath. 

5.2. Algorithm by Detecting the Heaviest Failure State 

In algorithm SplitPath and CheckSpurious-I, always, the first failure state is 
detected. Then further refinement will be done based on the analysis of this failure 
state. Possibly, several failure states may occur in one counterexample, so which 

Algorithm 2 : CheckSpurious-IICE) 

Input: a counterexample TI =< so,si,...,Sn > in the abstract model K = 
{S ,So,R,L), and the original model ^ = (S,So,R,L) 
Output: the heaviest failure state Sf 

1: Sorting: the heavier the earlier (stored in array int w[n + 1]); 

2; Initialization: int i = 0; 

3: while i <ndo 

4: if /n^jj-j n Outs~yf^ Q, i = i + \ ; 
5: else return sj = break; 
6: end while 

7: if z == n + 1, return fl is a real counterexample; 



one is chosen to be refined is not considered in SplitPath. Obviously, if a failure 
state shared by more paths is refined, a number of model checking iterations will 
be saved in the whole abstract-refinement loop. With this consideration, we will 
check the states which is shared by more paths first. To do so, for an abstract 
state s as illustrated in Figl6l EIn{s) and EOut(s) are defined. Eln(s) equals to the 
number of edges connecting to the states in /i (5) from the states outside of /i (5); 
and EOut{s) is the number of edges connecting to the states out of h~{s) from the 
states in /z (5). Accordingly, EIn{s) x EOut{s) is the number of the paths where s 
occurs. For convenience, we call Eln(s) x EOut(s) the weight of the abstract state 
s. Based on this, algorithm CheckSpurious-II is given for detecting the heaviest 
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Figure 6: In and out edg( 



failure state in a counterexample. In CheckSpurious-II, an array w[ i] is used to 
store the indexes of the states in the counterexample by the heavier the earlier. 

5.3. Parallel Algorithms 

Considering whether or not a state Sj is a failure state only relies on the pre- 
and post- states, Siii and s^-i, of Sj, the algorithm can be naturally paralleled as 
presented in algorithm CheckSpurious-III and CheckSpurious-IV. 

In CheckSpurious-III, anytime, if a failure state is detected by a processor, all 
the processors will be stop and the failure state is returned. Otherwise, if no failure 
states are reported, the counterexample is a real one. That is the algorithm always 
reports the first detected failure state obtained by the processors. Note that a 
boolean array c[n] is used to indicate whether or not a state in the counterexample 
is a failure one. Initially, for all < i < n, c[i] is undefined {c[i] = ±). c[i] == true 
means state 5, is not a failure state. 

Algorithm 3 : CheckSpurious-IIICIT) 

Input: a counterexample n =< So,Si,...,Sn > in the abstract model K = 

(5 , 5 0, R, L), and the original model K = (5 , 5 o, R, L) in shared memory 

n: the number of processors 

k: processor id 

Output: a failure state Sf 

1: Initialization: bool c\n + 1] = {±, ±}; 

2: for = to n do in parallel do 

3: if n Outsi^ 4^ 0, c\k\ = ture; 

4: else return sj = 4; stop all processors; 

5: end for 

6: if for all < i < n, c[i] == ture, return ft is a real counterexample; 



In CheckSpurious-IV, the weight of the states are considered, and always the 
heaviest failure state is found. 
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Algorithm 4 : CHECKSpuRious-IV(n) 

Input: a counterexample tl =< so,Si,...,Sn > in the abstract model K = 

(5 , 5"o, R, L), and the original model K = (5 , 5 o, R, L) in shared memory 

n: the number of processors 

k: processor id 

Output: a failure state Sf 

1: Sorting: the heavier state first (stored in array int w[n + 1]); 

2: for = to n do in parallel do 

3: iflris^ n Outs'^ ^ 0, c[k] = ture; 

4: else return c[k] = false; 

5: end for 

6: if for all I < i < n, c[i] = ture, return n is a real counterexample; 
7: else return Sf = Si such that c[i\ == false, and for any state Sj, if the weight 
of Sj is heavier than Si, c[j] == true; 



6. Conclusion 

Based on a formal definition of spurious paths, a novel approach for detect- 
ing spurious counterexamples are presented in this paper. In the new approach, 
whether or not a state f, is a failure state only relies on 5,'s pre- and post- states 
in the counterexample. So, for infinite counterexample, the polynomial number 
of unwinding of the loop can be avoided. Further, the algorithm can be easily 
improved by detecting the heaviest failure state such that a number of model 
checking iterations can be saved in the whole abstract-refinement loop. Also, 
the algorithm can be naturally parallelled. 

The presented algorithms are useful in improving the abstract based model 
checking, especially the counterexample guided abstraction refinement model check- 
ing. In the near future, the proposed algorithm will be implemented and integrated 
into the tool CEGAR. Further, some case studies will be conducted to evaluate the 
algorithms. 
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